<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Task: Define System Context</title>
<meta name="uma.type" content="Task">
<meta name="uma.name" content="define_system_context">
<meta name="uma.presentationName" content="Define System Context">
<meta name="uma.category" content="Discipline:rup_analysis_design_discipline:分析与设计">
<meta name="element_type" content="activity">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../css/default.css" type="text/css">
<script src="./../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../';
					var imgPath = './../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo, '', true, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top">
<div id="page-guid" value="_Ub-SUN90EdmvvvV6NEU6eA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Task: Define System Context</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../images/task.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This task defines how to a create a system context diagram that shows the top-level collaboration between the system and its actors.</td>
</tr>
<tr>
<td>Disciplines: <a href="./../../rup/disciplines/rup_analysis_design_discipline_29760231.html" guid="_ydt62NnmEdmO6L4XMImrsA">分析与设计</a></td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Purpose</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><ul class="noindent">
    <li>
        Based on the Use-Case Model,&nbsp; to create a top-level collaboration showing the system (modeled as a top-level
        subsystem), its interfaces and its relationships with its actors, including the external I/O entities that flow
        between actor and system.
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Roles</th><td class="sectionTableCell" width="42%"><span class="sectionTableCellHeading">Primary Performer:
								</span>
<ul>
<li>
<a href="./../../rup/roles/rup_system_analyst_C3C9C9AC.html" guid="{F1F206DF-3AA0-4AC0-92EF-8E4A01B6C5B5}">系统分析人员</a>
</li>
</ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">Additional Performers:
								</span>
<ul>
<li>
<a href="./../../rup/roles/rup_software_architect_DB0BF177.html" guid="{4AC346F0-E6FC-4D2C-8410-2EDF8DDDC91D}">软件架构师</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Inputs</th><td class="sectionTableCell" width="42%"><span class="sectionTableCellHeading">Mandatory:
								</span>
<ul>
<li>
<a href="./../../rup/workproducts/rup_supplementary_specification_F5ACAA22.html" guid="{B16C2941-791C-44E6-B353-354109B5C9DE}">补充规约</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_analysis_model_76C3B70C.html" guid="{98EA224C-36F6-46E6-AB36-2999382B58B3}">分析模型</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_usecase_model_EF15E534.html" guid="{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}">用例模型</a>
</li>
</ul>
<ul></ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">Optional:
								</span>
<ul>
<li>None</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Outputs</th><td class="sectionTableCell" colspan="2">
<ul>
<li>
<a href="./../../rup/workproducts/rup_operation_AD3B6CA6.html" guid="_vGkssN90EdmvvvV6NEU6eA">操作</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_analysis_model_76C3B70C.html" guid="{98EA224C-36F6-46E6-AB36-2999382B58B3}">分析模型</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_usecase_model_EF15E534.html" guid="{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}">用例模型</a>
</li>
</ul>
<ul></ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Steps</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="sectionTableSingleCell">
<div class="stepHeading">Introduction</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Whereas the Use-Case Model shows the behavioral context for the system, in this task you create a logical model of the
    system in its environment, using the <a class="elementLinkWithType" href="./../../rup/workproducts/rup_usecase_model_EF15E534.html" guid="{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}">Artifact: 用例模型</a>&nbsp;and the&nbsp;<a class="elementLinkWithType" href="./../../rup/workproducts/rup_supplementary_specification_F5ACAA22.html" guid="{B16C2941-791C-44E6-B353-354109B5C9DE}">Artifact: 补充规约</a> to delineate, in a <i>Context Diagram:</i>
</p>
<ul>
    <li>
        The interfaces to be <i>realized</i> by the system (in terms of the <i>operations</i> the systems provides, and the
        associated protocols supported, the <i>state variables</i> and <i>stores</i> that the system realizes, and
        attributes characterized as <i>Technical Performance Measures</i>).
    </li>
    <li>
        The <i>I/O entities</i> that flow between the system and its actors.
    </li>
    <li>
        The interfaces <i>required</i> by the system (to be realized by the actors which interact with the system) for
        correct performance. Often, if the actor represents an existing system with which the system must communicate,
        these required interfaces simply reflect constraints imposed by that other system.
    </li>
</ul>
<p>
    A context diagram shows the top-level collaboration between the system and its actors. It is the structural analog to
    the Use-Case Model for the system. This collaboration is created in the Analysis Model.
</p>
<p>
    I/O entities (represented for modeling as "I/O" stereotyped classes with attributes but no operations) describe things
    that flow into or out of the system, and can, in the general system case, include data, mass, energy, or physical
    parts. I/O entities are associated (during modeling) with actor-system pairs, indicating that these particular I/O
    entities flow between actor and system. They can optionally be shown on the diagrams, associated with the actor, and
    the direction of flow is indicated by a stereotype "send"or "receive" on the association, indicating the direction
    relative to the actor.
</p>
<p>
    A System Operation is a service that can be requested from an object to effect behavior. An operation specifies the
    name, type, parameters, and constraints for invoking an associated behavior. The Operations are grouped around
    interfaces along the main responsibilities of the (sub)system under consideration. A system operation invocation
    represents a finer grained interaction with the system than a use-case instance, and a use-case instance is a
    composition of operation invocations and responses.
</p>
<p>
    State variables and stores are attributes defined on the interfaces realized by the system. These are abstract and
    require that the system maintain information corresponding to the type and multiplicity of the attribute and permit
    storage, retrieval and modification of that information. There is no implication that there an attribute in the system
    directly corresponds to the attribute defined at the interface. The difference between state variables and stores is
    not intrinsic, it just reflects the way the attributes are used to control the operation of the system's (abstract)
    state machine. A "state" persists over a period of time, unlike an event (such as the arrival of a signal) that occurs
    at a point in time. The state machines mentioned here are finite state machines, and the delineation of "state" is
    usually decided by relatively few variables; for example, the current state could be specified by the value of a single
    attribute of an enumeration type. The reaction of the system however, to an event, might depend not only on the nature
    of the event (and the information it carries, for example, in the operation parameters), and the current state, but
    also on the value of (perhaps many) other attributes.
</p>
<p>
    A Technical Performance Measure (TPM) is a key technical attribute selected from the Supplementary Specifications or
    Use-Case Model as a critical indicator of system effectiveness, that, if not achieved, puts the system development at
    risk of overrunning cost, schedule or performance constraints. The emerging values of such attributes are tracked over
    the project lifetime. For example, it might be important that the delivered weight of a system be kept below a certain
    limit, and the achievement of this target needs to be tracked as design and construction proceeds. The weight of the
    system as delivered is obviously an attribute (which can be sensed in various ways) of an instance of the system, and
    is not necessarily the same as the target weight during development (for a system to be launched into orbit you would
    probably like it to be less). A UML tagged value can be used to annotate a TPM attribute to indicate the performance
    target, for example:
</p>
<p>
    <font face="Arial" size="2">"TPM" weight {maximum_weight = 1000kg} <!--Is this example expressed correctly? --></font>
</p>
<p>
    Technical Performance Measures can also apply to other non-structural characteristics such as operation response time.
    Tagged values can be applied to system operations, or the system itself, to record these.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">Create initial Context Diagram</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    The following steps show evolving levels of detail of the system in context. The example illustrated is that of a
    security system, protecting property from unauthorized intrusion, which, in addition to sounding an alarm, has the
    ability to report breaches to some kind of response service.&nbsp;
</p>
<p>
    As you evolve and add more detail to the Use-Case Model (discovering the actors; or if Business Modeling has been
    performed, and actors and perhaps operations already identified, elaborating their interaction), you can create the
    initial collaboration and illustrate this with a Context Diagram. The Context Diagram can be created as shown,
    initially with the system interfaces abstracted away. The system is depicted as a top-level subsystem (stereotyped
    "system"), which eventually realizes several interfaces. Actors and their associations are also shown, again, with no
    detail initially.
</p>
<p align="center">
    <img height="369" src="./../../rup/tasks/resources/ecd1.gif" width="406" alt="Context diagram (initial)" border="0" />
</p>
<p class="systemsengineeringpicturetext" align="center">
    Context Diagram (initial)
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">Refine associations and interfaces</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Next, you refine the associations between actors and system, and the system interface. You can start to reason about
    the system operations and the system attributes as they emerge from&nbsp;<a class="elementLinkWithType" href="./../../rup/tasks/find_actors_and_use_cases_1ACB35F0.html" guid="{3CD5FA7E-160C-4A39-9DEB-C6D162D8AECD}">Task: 查找参与者和用例</a> (Later: <a class="elementLinkWithType" href="./../../rup/tasks/detail_a_use_case_D9BECBF4.html" guid="{536BC669-A8FB-426D-88FF-CBEA806A9066}">Task: 详细描述用例</a>). Note that now the system appears to the actors, by
    showing the interface. The realization of this can be shown if you wish (highlighted by the dashed circle in the
    diagram), but can be omitted without much loss of information.
</p>
<p>
    At this stage, only tentatively identify the I/O entities, based on domain knowledge and any work done previously in
    realizing use cases at the enterprise level.&nbsp;Note that it is not required that the I/O entities be shown on the
    diagram, but this can be helpful in reasoning about actor-system interactions.
</p>
<p>
    Thus, you can start to characterize the connection(s) between actor and system (for example, record the protocol
    required) and record the entities that flow between them.
</p>
<p align="center">
    <img height="539" alt="Context diagram (preliminary)" src="./../../rup/tasks/resources/ecd2.gif" width="424" border="0" />
</p>
<p class="systemsengineeringpicturetext" align="center">
    Context Diagram (preliminary)
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">Detail system operations and other system characteristics</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    In this step, you start to construct use-case scenarios (instances of use cases) from which you can describe system
    operations (provided and required). The scenarios can be illustrated by interaction or activity diagrams. Each
    black-box step in a use case represents a finer-grained interaction with the system and maps to a operation invocation
    (but not necessarily a unique operation; other black-box steps might use the same operation). As well as defining the
    system operations in the Context Diagram (and hence in the Analysis Model), the use cases are also annotated, for
    traceability, to the operations invoked. The operations also inherit any performance requirements or other
    non-functional requirements that have been allocated to the black-box steps. As you examine each black-box step
    performed in the scenario, you discover the use of names that might suggest state variables and stores that the system
    must maintain&nbsp;to execute the use-case scenario. You can also refine the I/O entities that are required and
    associate these with operation invocations to form the signals sent between actor and system.&nbsp;
</p>
<p>
    It might aid understanding to divide the system interface into more specific interfaces; indeed, there can be interface
    requirements in the Supplementary Specification which drive this. The illustration below shows the evolution of the
    system interface into a "provided system interface" for each actor type, although this is not a fixed prescription.
    Actors might share an interface, or there could be more than one interface for an actor.
</p>
<p>
    This analysis might also identify interfaces <i>required</i> by the system, that is, interfaces that must be supported
    by the actors (to process messages from the system). These can be added to the diagram in a symmetrical way (for
    example, see the IE-services/ESS "required system interface" realized by the Emergency Services actor in the diagram
    below).&nbsp;Again, (although this is not shown) an actor might support (realize) more than one interface.
</p>
<p>
    The operations, stores and so forth., need to be added to an expanded form of the interfaces (in the attribute and
    operation compartments) as shown. The diagram is only partially elaborated (in the interests of space). The physical
    environment interface, actor and so forth, have not been expanded. Again, the realization of the provided system
    interfaces can be omitted without much loss of information.
</p>
<p align="center">
    <img height="293" src="./../../rup/tasks/resources/ecd3.gif" width="669" alt="Context diagram (final)" border="0" />
</p>
<p class="systemsengineeringpicturetext" align="center">
    Context Diagram (final).
</p>
<p>
    This top-level collaboration, captured in the Context Diagram, allows the interfaces, connections, what flows into and
    out of the system, and associated performance characteristics, to be rigorously specified, enabling system development
    to proceed somewhat independently from other elements in the system's context.<br />
    <br />
</p></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
